Секретний інгредієнт React: глибоке занурення в алгоритм Reconciliation та дифінг віртуального DOM

` може бути представлений так:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

Оскільки це лише об'єкти JavaScript, їх створення та маніпуляція відбуваються неймовірно швидко. Це не вимагає взаємодії з API браузера, тому не відбувається жодних перекомпонувань чи перемальовувань.

Як працює віртуальний DOM?

VDOM уможливлює декларативний підхід до розробки UI. Замість того, щоб крок за кроком вказувати браузеру, як змінити DOM (імперативний підхід), ви просто оголошуєте, яким має бути UI для певного стану (декларативний підхід). React робить усе інше.

Процес виглядає так:

1. Початковий рендеринг: Коли ваш додаток завантажується вперше, React створює повне дерево віртуального DOM для вашого UI і використовує його для генерації початкового реального DOM.
2. Оновлення стану: Коли стан додатка змінюється (наприклад, користувач натискає кнопку), React створює нове дерево віртуального DOM, яке відображає новий стан.
3. Дифінг (порівняння): Тепер React має в пам'яті два дерева віртуального DOM: старе (до зміни стану) і нове. Потім він запускає свій алгоритм "дифінгу" для порівняння цих двох дерев та виявлення точних відмінностей.
4. Пакетування та оновлення: React обчислює найефективніший та мінімальний набір операцій, необхідних для оновлення реального DOM, щоб він відповідав новому віртуальному DOM. Ці операції пакетуються разом і застосовуються до реального DOM в єдиній оптимізованій послідовності.

Завдяки пакетуванню оновлень React мінімізує пряму взаємодію з повільним DOM, значно покращуючи продуктивність. Ядро цієї ефективності полягає в етапі "дифінгу", який формально відомий як алгоритм Reconciliation.

Серце React: алгоритм Reconciliation

Reconciliation — це процес, за допомогою якого React оновлює DOM, щоб він відповідав найновішому дереву компонентів. Алгоритм, що виконує це порівняння, ми називаємо "алгоритмом дифінгу".

Теоретично, знаходження мінімальної кількості перетворень для конвертації одного дерева в інше є дуже складною проблемою зі складністю алгоритму порядку O(n³), де n — кількість вузлів у дереві. Це було б занадто повільно для реальних додатків. Щоб вирішити цю проблему, команда React зробила кілька геніальних спостережень щодо типової поведінки веб-додатків і впровадила евристичний алгоритм, який працює набагато швидше — за час O(n).

Евристики: як зробити дифінг швидким та передбачуваним

Алгоритм дифінгу React побудований на двох основних припущеннях, або евристиках:

Евристика 1: Елементи різних типів створюють різні дерева

Це перше і найпростіше правило. Порівнюючи два вузли VDOM, React спочатку дивиться на їхній тип. Якщо тип кореневих елементів відрізняється, React припускає, що розробник не хоче намагатися перетворити один на інший. Замість цього він обирає більш радикальний, але передбачуваний підхід:

• Він руйнує все старе дерево, демонтуючи всі старі компоненти та знищуючи їхній стан.
• Він будує абсолютно нове дерево з нуля на основі нового типу елемента.

Наприклад, розглянемо таку зміну:

До: <div><Counter /></div>
Після: <span><Counter /></span>

Незважаючи на те, що дочірній компонент `Counter` залишився тим самим, React бачить, що корінь змінився з `div` на `span`. Він повністю демонтує старий `div` і екземпляр `Counter` всередині нього (втрачаючи його стан), а потім змонтує новий `span` і абсолютно новий екземпляр `Counter`.

Ключовий висновок: Уникайте зміни типу кореневого елемента піддерева компонентів, якщо ви хочете зберегти його стан або уникнути повного перерендерінгу цього піддерева.

Евристика 2: Розробники можуть вказувати на стабільні елементи за допомогою пропа `key`

Це, мабуть, найважливіша евристика, яку розробники повинні розуміти та правильно застосовувати. Коли React порівнює список дочірніх елементів, його поведінка за замовчуванням — ітерувати по обох списках одночасно і генерувати мутацію там, де є різниця.

Проблема дифінгу на основі індексів

Уявімо, що у нас є список елементів, і ми додаємо новий елемент на початок списку, не використовуючи ключі.

Початковий список:

• Елемент B
• Елемент C

Оновлений список (додаємо 'Елемент A' на початок):

• Елемент A
• Елемент B
• Елемент C

Без ключів React виконує просте порівняння на основі індексів:

1. Він порівнює старий елемент з індексом 0 ('Елемент B') з новим елементом з індексом 0 ('Елемент A'). Вони різні, тому він мутує перший елемент.
2. Він порівнює старий елемент з індексом 1 ('Елемент C') з новим елементом з індексом 1 ('Елемент B'). Вони різні, тому він мутує другий елемент.
3. Він бачить, що є новий елемент з індексом 2 ('Елемент C'), і вставляє його.

Це вкрай неефективно. React виконав дві непотрібні мутації та одну вставку, тоді як усе, що було потрібно, — це одна вставка на початку. Якби ці елементи списку були складними компонентами з власним станом, це могло б призвести до серйозних проблем із продуктивністю та помилок, оскільки стан міг би переплутатися між компонентами.

Сила пропа `key`

Проп `key` пропонує рішення. Це спеціальний рядковий атрибут, який потрібно включати при створенні списків елементів. Ключі надають React стабільну ідентичність для кожного елемента.

Повернімося до того ж прикладу, але цього разу зі стабільними, унікальними ключами:

Початковий список:

• Елемент B
• Елемент C

Оновлений список:

• Елемент A
• Елемент B
• Елемент C

Тепер процес дифінгу в React набагато розумніший:

1. React дивиться на дочірні елементи нового списку і знаходить елементи з ключами 'b' та 'c'.
2. Він знає, що елементи з ключами 'b' та 'c' вже існують у старому списку, тому він просто переміщує їх.
3. Він бачить, що є новий елемент з ключем 'a', якого раніше не було, тому він створює і вставляє його.

Це набагато ефективніше. React правильно визначає, що потрібно виконати лише одну вставку. Компоненти, пов'язані з ключами 'b' та 'c', зберігаються, підтримуючи свій внутрішній стан.

Критичне правило для ключів: Ключі мають бути стабільними, передбачуваними та унікальними серед своїх сусідів. Використання індексу масиву як ключа (`items.map((item, index) =>

...

)`) є антипатерном, якщо список може бути пересортований, відфільтрований або якщо елементи можуть додаватися/видалятися зсередини, оскільки це призводить до тих самих проблем, що й відсутність ключа взагалі. Найкращі ключі — це унікальні ідентифікатори з ваших даних, наприклад, ID з бази даних.

Еволюція: від стекової до Fiber-архітектури

Описаний вище алгоритм Reconciliation був основою React протягом багатьох років. Однак у нього було одне суттєве обмеження: він був синхронним і блокуючим. Цю оригінальну реалізацію тепер називають Stack Reconciler.

Старий підхід: Stack Reconciler

У Stack Reconciler, коли оновлення стану викликало перерендерінг, React рекурсивно обходив усе дерево компонентів, обчислював зміни та застосовував їх до DOM — все це в одній, неперервній послідовності. Для невеликих оновлень це було нормально. Але для великих дерев компонентів цей процес міг займати значний час (наприклад, понад 16 мс), блокуючи основний потік браузера. Це призводило до того, що UI переставав відповідати, спричиняючи пропущені кадри, "рвані" анімації та поганий користувацький досвід.

Представляємо React Fiber (React 16+)

Щоб вирішити цю проблему, команда React взялася за багаторічний проєкт повного переписування основного алгоритму Reconciliation. Результат, випущений у React 16, називається React Fiber.

Архітектура Fiber була розроблена з нуля для забезпечення конкурентності — здатності React працювати над кількома завданнями одночасно і перемикатися між ними на основі пріоритету.

"Файбер" — це простий об'єкт JavaScript, який представляє одиницю роботи. Він містить інформацію про компонент, його вхідні дані (пропси) та його вивід (дочірні елементи). Замість рекурсивного обходу, який не можна було перервати, React тепер обробляє зв'язний список файбер-вузлів, один за одним.

Ця нова архітектура відкрила кілька ключових можливостей:

• Інкрементальний рендеринг: Вона може розбивати роботу з рендерингу на невеликі частини та розподіляти її на кілька кадрів.
• Пріоритезація: Вона може призначати різні рівні пріоритету різним типам оновлень. Наприклад, введення тексту користувачем у полі вводу має вищий пріоритет, ніж отримання даних у фоновому режимі.
• Можливість призупинення та скасування: Вона може призупинити роботу над низькопріоритетним оновленням для обробки високопріоритетного, і навіть скасувати або повторно використати роботу, яка більше не потрібна.

Дві фази Fiber

В архітектурі Fiber процес рендерингу розділений на дві чіткі фази:

1. Фаза рендерингу/узгодження (асинхронна): У цій фазі React обробляє файбер-вузли для побудови "робочого" дерева (work-in-progress tree). Він викликає методи `render` компонентів і запускає алгоритм дифінгу для визначення змін, які потрібно внести до DOM. Важливо, що ця фаза є перериваною. React може призупинити цю роботу, щоб обробити щось важливіше, і відновити її пізніше. Оскільки її можна перервати, React не застосовує жодних фактичних змін до DOM під час цієї фази, щоб уникнути неузгодженого стану UI.
2. Фаза коміту (синхронна): Як тільки "робоче" дерево завершено, React переходить до фази коміту. Він бере обчислені зміни і застосовує їх до реального DOM. Ця фаза є синхронною і не може бути перервана. Це гарантує, що користувач завжди бачить узгоджений UI. Методи життєвого циклу, такі як `componentDidMount` та `componentDidUpdate`, а також хуки `useLayoutEffect` та `useEffect`, виконуються під час цієї фази.

Архітектура Fiber є основою для багатьох сучасних функцій React, включно з `Suspense`, конкурентним рендерингом, `useTransition` та `useDeferredValue`, які допомагають розробникам створювати більш чутливі та плавні користувацькі інтерфейси.

Практичні стратегії оптимізації для розробників

Розуміння процесу Reconciliation в React дає вам змогу писати більш продуктивний код. Ось кілька практичних стратегій:

1. Завжди використовуйте стабільні та унікальні ключі для списків

На цьому неможливо не наголосити. Це єдина найважливіша оптимізація для списків. Використовуйте унікальний ID з ваших даних (наприклад, `product.id`). Уникайте використання індексів масиву, якщо тільки список не є повністю статичним і ніколи не зміниться.

2. Уникайте зайвих перерендерінгів

Компонент перерендериться, якщо змінюється його стан або перерендериться його батьківський компонент. Іноді компонент перерендериться, навіть якщо його вивід буде ідентичним. Ви можете запобігти цьому, використовуючи:

• `React.memo()`: Компонент вищого порядку для функціональних компонентів. Він виконує поверхневе порівняння пропсів компонента. Якщо пропси не змінилися, React пропустить перерендерінг компонента і повторно використає останній відрендерений результат.
• `useCallback()`: Функції, визначені всередині компонента, створюються заново при кожному рендері. Якщо ви передаєте ці функції як пропси дочірньому компоненту, обгорнутому в `React.memo`, дочірній компонент все одно перерендериться, тому що проп-функція технічно є новою функцією щоразу. `useCallback` мемоізує саму функцію, гарантуючи, що вона буде створена заново лише якщо зміняться її залежності.
• `useMemo()`: Схожий на `useCallback`, але для значень. Він мемоізує результат дорогого обчислення. Обчислення виконується повторно лише якщо одна з його залежностей змінилася. Це корисно для запобігання дорогим обчисленням при кожному рендері та для підтримки стабільних посилань на об'єкти/масиви, що передаються як пропси.

3. Розумна композиція компонентів

Спосіб структурування компонентів може суттєво вплинути на продуктивність. Якщо частина стану вашого компонента часто оновлюється, спробуйте ізолювати її від частин, які не оновлюються.

Наприклад, замість того, щоб мати один великий компонент, де поле вводу, що часто змінюється, викликає перерендерінг усього компонента, винесіть цей стан у свій власний, менший компонент. Таким чином, лише маленький компонент буде перерендеритися, коли користувач вводить текст.

4. Віртуалізація довгих списків

Якщо вам потрібно відрендерити списки з сотнями або тисячами елементів, навіть з правильними ключами, рендеринг усіх їх одночасно може бути повільним і споживати багато пам'яті. Рішенням є віртуалізація або "віконізація" (windowing). Ця техніка полягає в рендерингу лише невеликої підмножини елементів, які наразі видимі у в'юпорті. Коли користувач прокручує, старі елементи демонтуються, а нові монтуються. Бібліотеки, такі як `react-window` та `react-virtualized`, надають потужні та прості у використанні компоненти для реалізації цього патерну.

Висновок

Продуктивність React — це не випадковість; це результат продуманої та складної архітектури, зосередженої навколо віртуального DOM та ефективного алгоритму Reconciliation. Абстрагуючись від прямої маніпуляції DOM, React може пакетувати та оптимізувати оновлення таким чином, яким було б неймовірно складно керувати вручну.

Як розробники, ми є важливою частиною цього процесу. Розуміючи евристики алгоритму дифінгу — правильно використовуючи ключі, мемоізуючи компоненти та значення, і вдумливо структурувуючи наші додатки — ми можемо працювати разом з reconciler'ом React, а не проти нього. Еволюція до архітектури Fiber ще більше розширила межі можливого, уможлививши нове покоління плавних та чутливих UI.

Наступного разу, коли ви побачите, як ваш UI миттєво оновлюється після зміни стану, знайдіть хвилинку, щоб оцінити елегантний танець віртуального DOM, алгоритму дифінгу та фази коміту, що відбувається "під капотом". Це розуміння — ваш ключ до створення швидших, ефективніших та надійніших додатків на React для глобальної аудиторії.